Adding Application Dependencies

Problem statement#

Helm allows us to define templates. While that works great for our applications, it might not be the best idea for third-party apps.

Our application requires a database. To be more precise, it needs MongoDB. Now, we might say, “It should be easy to define the resources for MongoDB,” but that could quickly turn into a false statement.

But, the real question is not whether we can define everything we need to deploy and manage MongoDB. Rather, the question is whether that’s a worthwhile investment. More often than not, it’s not worth our time. Whenever possible, we should focus on what brings differentiating value. In most cases, that means we should focus mostly on developing, releasing, and running our own applications, and using services from other vendors and community knowledge for everything else. MongoDB is not an exception.

Adding the dependencies#

Helm contains a massive library of charts maintained both by the community and vendors. All we have to do is find the one we need and add it as a dependency.

Let’s see yet another YAML file requirements.yaml. The output is as follows.

The requirements.yaml file is optional. If we do have it, we can use it to specify one or more dependencies. In our case, there’s only one dependency.

The name of the dependency must match the name of the chart that we want to use as a dependency. However, that alone can result in conflicts, given that multiple applications running in the same namespace might use the same chart as a dependency. To avoid this issue, we specified an alias that provides a unique identifier, which should be used when deploying that chart instead of the “official” name of the chart.

Further on, we can see that we’re using the specific version of that chart and that it’s defined in the specific repository.

That is indeed an easy way to add almost any third-party application as a dependency. Furthermore, we could use the same mechanism to add internal applications as dependencies. But, the real questions are:

• How did we know which values to add?
• How did we know that the name of the chart is mongodb?
• How did we figure out that the version is indeed 7.13.0, and that the chart is in that repository?

Let’s go a few steps back and explore the process that helped us end up with that specific config.

Searching for mongodb#

The first step to finding a chart is often to search for it. That can be done through a simple Google search like “MongoDB Helm chart,” or through the helm search command. One suggestion is to start with the latter and resort to Google only if the chart is hard to find.

There are quite a few things we can observe from that output.

To begin with, all the charts, at least those related to mongodb, are coming from the stable repo. That’s the repository that is often the best starting point when searching for a Helm chart. We can see that there are at least four charts that contain the word mongodb. But, judging from the names, the stable/mongodb chart sounds like something we might need.

Later on, we have the latest version of the chart (CHART VERSION) and the version of the application it uses (APP VERSION).

Finally, we have a description, and the one for the mongodb chart is kind of depressing. It starts with DEPRECATED, giving us a clear indication that it’s no longer maintained.

Let’s take a quick look at the chart’s README and see whether we can get a clue as to why it was deprecated.

If we scroll to the top, we’ll see that there’s a whole subsection with the header This Helm chart is deprecated. In a nutshell, it tells us that the chart’s maintenance has been moved to Bitnami’s repository and is followed with short instructions on how to add and use their repository. While that might be seen as an additional complication, this situation is great, because it provides us with a chance to learn how to add and use additional repositories.

Next, we’ll confirm that the repo was indeed added by listing all those available locally through the Helm CLI.

helm repo list

The output is as follows.

Let’s see what happens if we search for MongoDB again.

helm search repo mongodb

The output is as follows.

We can see that, besides those from the stable repo, we got a few new results from bitnami.

Please note that one of the charts is bitnami/mongodb and that the chart version is, in our case, 7.13.0.

Reviewing requirements.yaml#

Let’s take another look at the requirements.yaml file we explored earlier.

The output is as follows.

The dependency we explored earlier should now make more sense. The repository is the same as the one we added earlier, and the version matches the latest one we observed through our output of helm search.

We can easily retrieve all the values available in a chart through yet another Helm command.

The output, limited to the relevant parts, is as follows.

We can see that MongoDB replication (ReplicaSet) is disabled by default. All we have to do to replicate it is to change the replicaSet.enabled value to true. And we already did that in the values.yaml file, so let’s take another look at it. The output, limited to the relevant parts, is as follows.

This time, we’re not trying to define a value of the main application, but for one of its dependencies. So, those related to the MongoDB are prefixed with go-demo-9-db. That matches the alias we defined for the dependency. Within that segment, we set replicaSet.enabled to true. That way, when we deploy the application with the go-demo-9-db dependency, the database will be replicated.

Try it yourself#

You can try all of the commands used in this lesson in the code playground below. Press the “Run” button and wait for a few seconds for it to connect.

For ease of use, all of the commands above are combined in main.sh.